Of Genericity and Other Daemons

This paper presents genericity in an historical fashion, by rst explaining how it is commonly presented intuitively, then by showing how this intuitive way, while convenient from a training point of view, is limited and can be extended signiicantly if completed using a more formal framework. The current implementation of param-eterized classes in the YAFL programming language 1] is then described in order to show how this improved formalization can be put to work. 1 Reuse, a short history Reuse is one of the Loch Ness monsters of the software industry. There have been many attempts to formalize, measure, encourage, and control software reuse. Besides administrative incentives and organizational changes required in order to change a software development organization into a reuse intensive building-block oriented factory, one can distinguish between three diierent kinds of software reuse from a technical point of view: Function libraries. Given a set of input parameters, a function performs some task, computes something, writes data to disk, generates a pseudo-random number, etc... This kind of reuse has been around for decades, and is still widely used in the scientiic community, where function libraries are available for virtually any numerical or semi-numerical problem one can think of. This kind of reuse is very limited in scope, since it only works in cases where the problem to be solved can be extracted context-free, and where the parameters are reasonably easy to specify. It is not a reuse of design. The data structures deened in a functional library cannot be altered easily to adapt to a given reuse environment. Inheritance. A given data type is deened together with attached behavior, and one can deene new data types derived from this data type, extending it, reusing some of its attached behaviors, overriding or extending methods. For yet another deenition of inheritance, please refer to 2].